大家好！我目前正在就讀資訊類科系，平常以接觸程式撰寫居多，對於資安領域的技術沒有太多了解因此希望藉由這30天的機會，以OWASP ZAP作為主要工具，從實際操作和分析，從環境架設、基本掃描到進階弱點發掘，一步步建立資安思維。
　　我將學習如何利用ZAP自動化及主動/被動掃描常見的資安漏洞，並理解其背後的原理，以及該如何修復，例如SQL Injection、XSS等，讓我從「資安小白」進化成具備基本滲透測試技能的「資安入門者」。

今日內容概要：

1. Authentication vs Authorization
2. 常見認證/授權協定與機制
3. JWT結構與驗證實務
4. 授權模型
5. Token Lifecycle
6. 常見的攻擊與預防方法

Authentication vs Authorization

身分識別（Authentication）： 確認「你是誰」。
-> 常見方式：密碼、OTP、多因素驗證（MFA）、第三方身分服務（例如 OAuth/OIDC 的登入流程）。

授權（Authorization）： 確認「你可以做什麼」。
-> 常見方式：角色基礎權限（RBAC）、屬性基礎存取控制（ABAC）、權限（scopes）、資源層級檢查（Object-level authorization / IDOR 檢查）。

常見認證、授權協定與機制

Session-based authentication

流程： 使用者登入 -> 伺服器建立session（ID存在伺服器）-> 將 session id放入cookie回傳給使用者 -> 後續請求以cookie驗證

優點： 伺服器可隨時使 session 失效（logout/revoke），較容易在伺服器端控制。
缺點： 難以水平擴展（需 session store/shared session），跨域與 API 呼叫處理較複雜。
**防護重點：**HttpOnly、Secure、SameSite 設定，CSRF token。

Token-based authentication

流程： 使用者或應用程式拿取 token（access token，常為 JWT），每次請求在 Authorization: Bearer<token>頭中帶上token。

優點： 無狀態（stateless），適合微服務、API 與跨域場景；易於擴展。
缺點： token 失效/撤銷管理複雜（需黑名單或短期有效 + refresh token 機制），JWT 若包含敏感資料需加密（JWE），否則只做簽章（JWS）。
防護重點： 驗證 signature、拒絕 alg:none、限制接受演算法、短生命週期、TLS。

OAuth 2.0(授權框架)

四種授權流程：

1. Authorization Code Grant（授權碼流程）
   -> 適用於同時有前端互動設計及後端伺服器(confidential client)的應用
   -> 優點： 支援Refresh Token、Token換發在伺服器端、PKCE解決在不安全環境(如mobile、SPA)上截取code的風險
   -> 缺點： 必須嚴格驗證redirect_url及使用state防CSRF、token與refresh token的儲存需存放在安全的資料庫及HttpOnly cookie
   -> 流程步驟：
   1. 使用者開啟客戶端(browser)，被導向Authorization Server的授權頁面（含client_id、redirect_uri、scope、state等）。
   2. 使用者同意授權後，Authorization Server用authorization_code重導回redirect_uri（包含code與state）。
   3. 客戶端後端用code向Authorization Server的token endpoint換取access_token及refresh_token，此請求需攜帶client_secret(confidential client)或PKCE的verifier(public client)。
   4. 後端取得token後，代表用戶於該client的存取權限，可向 Resource Server呼叫 API。

• 補充
  PKCE：client產生code_verifier（隨機字串），接著用SHA256產生 code_challenge，在第一階段，導向授權頁面時，帶code_challenge；在交換 token時，帶回code_verifier。
  ->有效防止中間人截取授權碼再獲取token（Auth Code Interception）

2. Client Credentials Grant(Server端互信)
   -> 適用於server-to-server的情境
   -> 優點： 只在後端運作，無使用者介入（簡單、安全）、適合微服務間的授權、機器人帳號、批次工作
   -> 缺點： token 表示 client 身份、非使用者。若需要代表使用者行為，應使用其他流程（如 Authorization Code）、client_secret必須安全儲存在HashCorp Vault、環境變數、KMS中、若需要細粒度資源擁有者權限（user-level），此流程不適用
   -> 流程步驟：
   1.伺服器A以client_id/client_secret向token endpoint發request（grant_type=client_credentials）。
   2. Authorization Server驗證憑證後回傳access_token。
   3. 伺服器A使用token呼叫受保護的Resource Server。

• 補充
  細粒度資源擁有者權限(user-level): 指在單一使用者層級上，授予特定使用者對特定資源的精確控制權限，而非僅限於一般性的「擁有者」權限。

3. Implicit Grant（隱式流程）
   -> 現已被Authorization Code Grant + PKCE替代
   -> 為前端應用所設計。是在授權頁面同意後，瀏覽器URL fragment (#access_token=...) 帶回token。

• 替代原因： token直接在瀏覽器中暴露，容易被透過瀏覽器歷史、HTTP Header-Referer、XSS或中間人截取，無法安全使用refresh token，也有洩漏風險。

4. Resource Owner Password Credentials Grant(ROPC)
   -> 用戶將帳號密碼直接提供給client，client 以該帳密向Authorization Server換取 token。(是在OAuth 2.0初期為方便認證而設計的)
   -> 可以用Authorization Code Grant替代

• 替代原因：
  • 客戶端取得使用者的密碼，增加密碼濫用風險，破壞密碼單一登入來源（IDP）的理念。
  • 不利於第三方應用限制存取
  • 難以支援MFA、SSO與現代安全流程，如OIDC。

OpenID Connect(OIDC)

-> 在OAuth 2.0基礎上增加 ID Token 與標準化身份資訊（claims），適合需要 SSO 與SAML斷言的場景。(ID Token通常為JWT)

SAML

全名Security Assertion Markup Language（安全斷言標記式語言），指在身分識別資訊提供者（Identity Provider，IdP）與服務提供者（Service Provider，SP）之間傳送驗證(基於XML的協議傳送)以及授權資料的一種公開標準。
-> 用於網頁瀏覽器的單一登入（Single Sign-On，SSO）

JWT(JSON Web Token)結構與驗證實務

是一種開放式標準(RFC 7519)，用於在不同方之間安全地傳輸資訊，並可通過數位簽名來驗證其真實性和完整性。
-> 通常包含三個部分：標頭(Header)、有效負載(Payload) 和 簽名(Signature)。
-> 主要用於身份驗證和授權，讓伺服器在驗證使用者身份後，將包含使用者資訊的JWT 回傳給前端，前端再透過每次的請求將此JWTt傳給伺服器，藉此可以確保用戶身份。